The entertainment industry is in the midst of a digital revolution. Music, television, and movies are increasingly becoming digital, offering new advantages to the consumer in quality and flexibility. At the same time, since digital data can be perfectly and quickly copied, the digital revolution also comprises a threat. If consumers may freely copy entertainment content and offer that content on the Internet, the market for entertainment content may evaporate.
Content protection schemes have been devised to lessen the threat, such as Digital Rights Management (DRM) systems, Content Scrambling System (CSS) for DVD video, and Content Protection for Prerecorded Media (CPPM) for DVD audio, among many others. These systems share the following feature: the software that implements them is required to be “robust,” that is the software resists attacks by hackers, either to extract the secrets (keys) from the software or to modify the software's behavior to get unauthorized functionality. Technologies that resist such attacks are called tamper-resistant software.
A common perception is that tamper-resistant software conflicts with the concept of “open source” on the premise that a hacker may more easily compromise an open source program. However, an open source content protection scheme presents definite advantages. Open standards may prevent fragmentation of the market and forestall proprietary solutions from locking out competition. In addition, an open source content protection scheme may actually help reduce the level of hacker attacks. The well-known break to the DVD video CSS scheme was enabled, in no small part, by leaks from insiders. These insiders were apparently motivated by the desire to have a DVD player on the open-source platform Linux.
Meanwhile, the Java® language has replaced the computer language C for many applications. The Java language is implemented by converting a source program to instructions (called byte codes) of a hypothetical computer referred to as the Java Virtual Machine, or Java virtual machine (“JVM”).
The Java virtual machine is not an actual hardware computer, instead it is a program that interprets the byte codes, and implements their functions on a given physical computer. This approach has given Java portability; the language is available in all types of computers and even in embedded devices such as cell phones, stereos, and TV set-top boxes.
Several companies have produced computers whose instruction set is the same as the Java virtual machine. In such a case, the Java virtual machine is real, not virtual. However, by convention, such a real computer is still called a “Java virtual machine”, a practice we will follow in the description of our invention.
One approach to content protection uses a Java virtual machine to implement the robustness requirements of content protection schemes. In this approach, all secret data and algorithms are not implemented in Java; instead, they are “wired in” to the Java virtual machine itself. Furthermore, the Java virtual machine provides a “sand box” environment so that unauthorized actions are prevented. For example, when the Java virtual machine is dealing with protected content, the normal file-writing mechanism of Java is disabled. Advantageously, there is no need to verify the integrity of the Java code itself.
This “sandbox” prevents any unauthorized behavior by the Java code. The important logic of each content protection scheme is hidden in the tamper resistant environment in the Java virtual machine itself. Although this technology has proven to be useful, it is desirable to present a solution where the secret data and algorithms do not need to be implemented in the Java virtual machine, they can be implemented in Java. Such a solution has the additional advantage that it can support the “open source” concept.
Most content protection applications involve secret data (keys) as opposed to secret algorithms. Some content protection schemes, such as watermarking schemes, also involve secret algorithms. It is relatively easy for hackers to deduce the original Java program from the byte codes. Traditional “byte-code obfuscation” programs actually do little to prevent this, merely obfuscating the names of variables, methods, and classes. What is needed is a solution that comprises strong cryptographic protection for the byte codes, if necessary.
Some content protection schemes utilize a “secure counter”. For example, a DVD audio user is permitted to make only a certain number of copies. A user may reset these counters by merely saving and restoring some files on his hard disk. A user may also copy his protected files to some friend, and thereby duplicate content the original user has purchased. What is needed is a solution that solves these basic breaches of content protection.
The Java language presents a concept of “public” versus “private”. Each method or subroutine is declared to be either public, private, or neither. The public methods were originally intended for the external interface of the Java application. Private methods were intended for all the functions within the Java application that may not be called externally. Methods that were neither public nor private were intended for use within a “package”, a group of related Java classes.
However, large Java applications comprise many Java “packages”, and consequently, almost every function has to be public. A hacker may exploit these public methods as “back doors”, causing the application to behave in an unauthorized way. Even within a single package, the hacker can simply defeat package protection by merely adding his own class to the package. It is difficult for an application designer to verify that he or she has not inadvertently exposed some internal but “public” interface that a hacker may exploit. What is needed is a virtual machine language that prevents exposure of methods and functions, moving the issue of security from the application to the virtual machine language.
Recently, several hardware proposals have been made to help software store secrets and verify integrity. For example, the Trusted Computer Platform Alliance has defined an open standard for such hardware. Similar proprietary technology has also been developed. These approaches use an all-or-nothing aspect. For an application to be trusted, the operating system requires trust. For the operating system to be trusted, the operating kernel requires trust. For the operating kernel to be trusted, the original boot code requires trust. Even benign changes to any level break the chain of trust.
One solution defines a new privilege level in the operating system. In this privilege level resides a subset of the kernel, a subset of the operating system, and all trusted applications. However, this proprietary approach gives the owner of this technology an enormous competitive advantage in building trusted applications, invalidating the concept of “open source”. What is needed is a solution that allows the development of “open source” applications that can still effectively exploit special security hardware.
Many Java designers have expressed a desire that applications written for a specific user or device not be transportable to other users or devices. Java designers wish to sell the application to a single user without the user being able to give or sell that application to other users. What is needed is a solution that prevents sharing of applications without permission from the application designer or owner.
What is therefore needed is a system, a computer program product, and an associated method for a secure or the trusted Java virtual machine that is capable of supporting tamper resistant application software while preserving the concept of “open source”. The need for such a solution has heretofore remained unsatisfied.